New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use G38.3 in qt_auto_probe_tool.ngc to be able to check probe status. #2562
base: 2.9
Are you sure you want to change the base?
Use G38.3 in qt_auto_probe_tool.ngc to be able to check probe status. #2562
Conversation
e5eb04d
to
997300a
Compare
These code changes seem good to me - have you tested the error process on a machine or sim? |
[c-morley]
These code changes seem good to me - have you tested the error process
on a machine or sim?
I could not get it to run in a simulator, and have not tested it on a
machine. The setup in that directory did not work in the simulator with
or without my change, and I did not understand what the problem was.
--
Happy hacking
Petter Reinholdtsen
|
There is a test after one of the G38.2 in question that look like this: O500 IF [#5070 EQ 0] G90 O500 return [-3] ; indicate probe contact failure to epilog O500 endif But the manual state that "If the probing operation failed, G38.2 and G38.4 will signal an error by posting an message on screen if the selected GUI supports that. And by halting program execution.". When I try to include a similar test in my test program, the program is aborted and the test is never executed. This make me believe the wrong G code is used. Or is there something special about the M6 remapping environment that make G38.2 behave differently? Made sure both calls to G38.2 are changed to G38.2 with a test verifying the status. Also adjusted the handling of the measured height to take any coordinate system offsets.
997300a
to
52ec2df
Compare
[c-morley]
Need brackets around the addition:
Ah, of course. Thank you for noticing. Fixed.
…--
Happy hacking
Petter Reinholdtsen
|
it seems there is also some needed changes in std_glue to get linuxcnc to notice the returned error numbers. Since it's a common library, I just don't know if it would break others relied on behavior. |
[c-morley]
it seems there is also some needed changes in std_glue to get linuxcnc
to notice the returned error numbers. Since it's a common library, I
just don't know if it would break others relied on behavior.
Which changes do you expect are needed? Are we talking about
nc_files/remap_lib/python-stdglue/stdglue.py? It seem to only check
return_value against 0.
Note, I did not add a new return value (-3), I only added another place
where the same return value was used. Similar code was already in place
after the second G38.2.
Still checking that code change yet,
Great to hear you are giving it a critical view. :)
Btw, Anyone know what the 'qt_' part of the qt_auto_probe_tool.ngc file
name mean?
…--
Happy hacking
Petter Reinholdtsen
|
QT because it was built for qtvcp's screens, though it should work for anyone. |
stuttgart meeting says @c-morley should decide on this. |
I'm happy to test this, I'm also working on pull request #2706, and @c-morley flagged this request there and asked if I could test. I've been delayed, and I apologize. But I have questions: It looks like from the comment at the beginning that the intention was to keep error codes... and I thought that was the difference between G38.2 and G38.3: that G38.2 returns an error code but G38.3 does not. The code has been changed to G38.3 at lines 69 and 79. But the comment at the beginning seems to include an ambiguous typo:
Assuming what was meant is "change G38.2 to G38.3" I'm wondering if that will defeat getting an error message back?? Those questions aside: how do I test this? We are only talking about testing the QtDragon GUI, right? Or is this routine used in the other GUIs? (I've been using it on QtDragon) My thought is to set up my machine so that the _ini[VERSA_TOOLSETTER]MAXPROBE is too small to get from the _ini[VERSA_TOOLSETTER]Z down to the probe surface. Then I would set myself up to issue a T2M6 command. That will call this remap code and I should get an error back to the GUI because it won't be able to get a probe signal while it's doing line 69 or line 79 (since the backoffdist will be heading up from the insufficiently low maxprobe). Another thought: while I like very much the logical completeness of having the o600 section to check for the error after the reprobe... I nonetheless find myself wondering how that would actually every happen? There would have to be a probe failure of some kind between the success of line 69 and the start of line 79, otherwise 69 would have already failed. In fact, in order to test it, I think I would have to move the probe out of the way after the rapid probe and before the slow reprobe could get there. Hmmm. Not sure I want to try that, mine is bolted on an upright support. Which, btw, brings me to: I have already gotten this error loads of times when my maxprobe distance is insufficient to reach the tool-setter. So, again I'm wondering if this switch to G38.3 is what is intended here, since it's been working for me without this change. On the other-hand, I'm hesitant about my knowledge here, so I'm very ready to be set straight, and thank you in advance. Please advise :-) |
There is a test after one of the G38.2 in question that look like this:
O500 IF [#5070 EQ 0]
G90
O500 return [-3] ; indicate probe contact failure to epilog
O500 endif
But the manual state that "If the probing operation failed, G38.2 and G38.4
will signal an error by posting an message on screen if the selected GUI
supports that. And by halting program execution.". When I try to include a similar
test in my test program, the program is aborted and the test is never executed.
This make me believe the wrong G code is used. Or is there something special
about the M6 remapping environment that make G38.2 behave differently?
Made sure both calls to G38.2 are changed to G38.2 with a test verifying the
status.
Also adjusted the handling of the measured height to take any coordinate system
offsets.